Provide a CorsSettings builder method to allow additional header ranges to be added, and the underlying ability to concatenate HttpHeaderRange instances to support it.

This supports scenarios where complex CorsSettings defaults are provided by downstream libraries (e.g. pekko-grpc) but still need to be extended/adapted by end user applications.

A concrete motivating example is the pekko-grpc defaultCorsSettings, which include:

  val defaultCorsSettings: CorsSettings = CorsSettings(ConfigFactory.load())
    .withAllowCredentials(true)
    .withAllowedMethods(immutable.Seq(HttpMethods.POST, HttpMethods.OPTIONS))
    .withExposedHeaders(immutable.Seq(headers.`Status`.name, headers.`Status-Message`.name, `Content-Encoding`.name))
    .withAllowedHeaders(
      HttpHeaderRange(
        "x-user-agent",
        "x-grpc-web",
        `Content-Type`.name,
        Accept.name,
        "grpc-timeout",
        `Accept-Encoding`.name))

In one of our (development) environments, we need the Authorization header to be added to the allowed headers range, but the withAllowedHeaders method only works by override, requiring us to either maintain our own distinct set of headers (which could diverge from the upstream) or do hacky matches on the unsealed HttpHeaderRange type.

This is a proposal for discussion on a more ergonomic/robust way to extend default settings like this.
The same pattern could equally be applied to the HTTP origin matchers and possibly the exposed headers.

I've tried to make the implementation in-line with conventions (e.g. I would prefer to seal scaladsl.model.HttpHeaderRange and have all the matches over it be required exhaustive, but the rest of pekko-http isn't really that way inclined), and the concat implementation is also awkward as exposing it to the Java DSL means you have to deal with those type params in the Scala methods and discourage extension.

Happy to discuss and rework if maintainers have opinions/better ideas about approach here.